fix(test): drive the shared-fetch follower's bounded wait to completion - #3631

The failure

A fully passing unit run exits 1:

ok | 376 passed (3341 steps) | 0 failed (1m14s)
error: Promise resolution is still pending but the event loop has already resolved

Zero failures, then a non-zero exit. Deno prints that when it is awaiting a
promise and the event loop goes empty underneath it — the awaited work can no
longer make progress, so the process aborts.

It ejected #3592, #3599, #3605 and release PR #3625 from the merge queue today
and blocked a local git push. Each ejection costs a full queue cycle.

It is one test, not a shard problem

It looked shard-agnostic — reported across coverage shards 1/8, 3/8, 4/8, 5/8
and 8/8, and sharding is index % 8 over a sorted file list, so no single file
can sit in five shards. The four failing logs I could retrieve cover shards 1/8,
4/8 and 6/8.

It is still one file. deno test --parallel streams a file's tests as they
finish, so a file that hangs part-way through still reports the tests that
already passed and then simply stops — the file is present in the log but
truncated, and its remaining tests are never counted. Reconstructing each
failing shard's expected file list and diffing it against the tests actually
reported gives, in every case, exactly one file with no completion line:

Same file, same twelve tests, every time. The thirteenth test is where it stops:
"returns a signal-less cache follower after its bounded wait". The shard
number varied only because files moved between shards as the tree changed
(#3596 moved cli/templates to templates/, for one).

Root cause

The test installs FakeTime, so it owns the clock: nothing advances unless the
test advances it.

The follower under test is deliberately signal-less — it passes no abort signal,
so waitForSharedInFlightHttpFetch gives it exactly one bounded wait and its
only release is its own timer, armed inside waitForInFlightFetch once the
follower's real filesystem work reaches that call.

The test waited for that work with time.runMicrotasks(), which drains
microtasks but never advances real I/O, and then advanced the clock by a fixed
HTTP_MODULE_FETCH_MAX_WAIT_MS. On a loaded runner the follower arms its timer
after the clock has already moved past its due time. No later advance ever
runs it, and await followerOutcome is then waiting on a fake timer while the
real event loop is empty — precisely the state Deno reports.

Both known symptoms of this test are the same race: the earlier
AssertionError at assertEquals(followerSettled, true) was the follower not
being ready yet; awaiting it instead turned the same race into a hang.

Reproduction

Deterministic: advance the clock synchronously with time.tick(...) instead of
time.tickAsync(...), which denies the follower the real event-loop turn a
loaded runner also denies it. On unmodified main that hangs 100% with the
exact CI signature:

returns a signal-less cache follower after its bounded wait ...
ok | 0 passed (12 steps) | 0 failed (6s)
error: Promise resolution is still pending but the event loop has already resolved

0 passed (12 steps) — the same twelve steps every CI log truncated at.

Natural: running the whole file repeatedly under heavy load reproduces it
without any modification. Captured live with the follower's state at the moment
of the hang:

run 5 PENDING-PROMISE | settled=false next=true inflight=1 waiters=2

next=true — a fake timer is scheduled; waiters=2 — the follower is still
inside its bounded wait, holding the timer nothing will run. Every passing run
shows settled=true next=false waiters=1.

--trace-leaks does not help here: this is not a leaked op. The op count is
zero, which is exactly why the loop drains.

The fix

Drive the work rather than assume a fixed span reaches it.

• Waiting for both callers to share the flight now yields to the real event
  loop (Deno.stat) as the file's existing runNextFakeTimer helper already
  does, instead of only draining microtasks — the follower gets there through
  real filesystem work.
• The follower is released by runFakeTimersUntil, which runs scheduled fake
  timers one at a time until it settles. A wait is reachable whenever it is
  armed, in any order.
• A step budget turns a genuinely stuck wait into a loud failure instead of a
  hang, so this can never again silently drop a whole test file.

No sanitizer opt-out (the ratchet stays 404/404), no blanket catch, no sleep, no
skipped test.

Regression test

"runs a bounded wait whose timer landed past a fixed clock advance" encodes the
property that matters: a wait armed past a single fixed advance still gets run.

Verified red against the old approach — replacing the helper body with the
previous fixed advance fails it cleanly, no hang:

runs a bounded wait whose timer landed past a fixed clock advance ... FAILED (6ms)
error: Error: The late-armed bounded wait did not settle within 200 fake timer steps

Verification

• Deterministic harness, same worst-case ordering both sides:
  5/5 hang before the fix, 5/5 clean after (1 passed (74 steps) each).
• Natural load loop on the unmodified file: 100 consecutive clean runs, 0 hits.
  The pre-fix rate at the same load was 1 in 10; 100 clean runs put that at
  p ≈ 3e-5.
• The regression test is green with the fix and fails cleanly without it.
• Full local deno task test:unit (pre-push gate): green.
• Sanitizer ratchet unchanged: Sanitizer opt-out baseline ok: 404/404.
• src/transforms/esm/http-cache.test.ts currently sits in coverage shard 4/8,
  which is green on this PR along with the other seven.

Not changed

runNextFakeTimer's two other callers already wait for a timer to exist before
running it, so they cannot advance past an unarmed wait — the exact defect here.
They are left alone. To be precise about what that does and does not buy: each
runs a single timer, so if one of them ever needed a second one it would have
the same shape, and runFakeTimersUntil is right there. Neither has shown up in
any failing log, so converting them now would be a speculative change to passing
tests.